home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000989_dsr@hplb.hpl.hp.com _Wed Apr 28 14:29:47 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA04449; Wed, 28 Apr 93 14:29:47 MET DST
  4. Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA12208; Wed, 28 Apr 1993 14:49:46 +0200
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 28 Apr 93 13:42:58 +0100
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA20117; Wed, 28 Apr 93 13:50:25 +0100
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9304281250.AA20117@manuel.hpl.hp.com>
  11. Subject: Re: Standardizing new HTML features... WE'RE INTERESTED!
  12. To: raisch@ora.com
  13. Date: Wed, 28 Apr 93 13:50:22 BST
  14. Cc: www-talk@nxoc01.cern.ch, mcrae@lib.ucsf.edu, dale@ora.com
  15. Mailer: Elm [revision: 66.36.1.1]
  16.  
  17. Rob Raisch writes:
  18.  
  19. > Dave,
  20. >        O'Reilly and Associates is *extremely* interested in helping you with
  21. > this effort.  We have a number of products in development which use HTML as
  22. > their technology base.  We see the future development of HTML to be of great
  23. > importance to our efforts.
  24.  
  25. Thank you, any help would be greatfully appreciated.
  26.  
  27. > I would suggest that lists and text flow are really exclusively
  28. > rendering issues.  When I want to make a nested list, I may wish to write it
  29.  
  30. ...
  31.  
  32. > But since there is no rendering information in HTML, and by definition there
  33. > cannot be, how the terms appear on the screen is left up to the renderer.
  34.  
  35. The current HTML standard as defined by the DTD forbids nested lists. It is
  36. therefore no surprise that the line mode browser doesn't support them. Other
  37. browsers have made extensions to the standard. It is certainly true, that the
  38. SGML DTD doesn't specify how such lists should be rendered, however, the
  39. accompanying description should provide sufficient guidelines, that authors
  40. will have an adequate idea of how each construct will appear. The current
  41. document says for example:
  42.  
  43.    "The representation of a list is not defined here, but a bulleted list for
  44.     unordered lists and a sequence of numbered paragraphs for an ordered list
  45.     would be quite appropriate. Other possibilities for interactive displays
  46.     include  embedded scrollable browse panels."
  47.  
  48. The current spec needs extension to define what kinds of nesting of list tags
  49. are permitted together with some comments on rendering issues.
  50.  
  51. > A form or table cannot be specified in HTML without breaking one of
  52. > HTML's first principles since forms and tables are descriptions of the
  53. > appearance of information in relationship to other elements and not the
  54. > description of information in terms of type and content.
  55.  
  56. I think you are mistaken here. Forms can be defined in terms of a collection
  57. of fields with specified types and allowed values. My proposal does indeed
  58. do this - leaving it up to the browser to decided how to render the form. One
  59. may also want to make it possible for authors to pass hints to browsers, but
  60. this is a separate issue. Tables too, can be specified without getting mixed
  61. up in the details of rendering, although some layout hints are useful.
  62.  
  63. Regards,
  64.  
  65. Dave Raggett